REMARKS 

This paper is submitted in reply to the Office Action dated July 1 1, 2006, within 
the three-month period for response. Reconsideration and allowance of all pending 
claims are respectfully requested. 

The Office Action has been issued subsequent to a restriction requirement that 
required restriction between two groups of claims, claims 1-2 and 17-19, and claims 3-16 
and 20, of which the first group of claims (1-2 and 17-19) was provisionally elected by 
Applicants. 

In the subject Office Action, claims 1-2, and 17-19 were objected to by the 
Examiner based upon informalities. Furthermore, claims 1-2, 17 and 19 were rejected 
under 35 U.S.C. § 103(a) as being unpatentable over U.S. Patent No. 6,738,779 to 
Shapira in view of U.S. Patent No. 6,785,677 to Fritchman, and claim 18 was rejected 
under 35 U.S.C. § 103(a) as being unpatentable over Shapira in view of Fritchman and 
further in view of U.S. Patent No. 5,845,276 to Emerson. 

Applicants respectfully traverse the Examiner's rejections to the extent that they 
are maintained. Applicants have now canceled claims 16 and 20 and amended claims 1- 
4, 7 and 17-19. Applicants respectfully submit that no new matter is being added by the 
above amendments, as the amendments are fully supported in the specification, drawings 
and claims as originally filed. 

As an initial matter, Applicants affirm the election of the Group 1 claims (claims 
1-2 and 17-19) without traverse, and as a result of this election, have canceled withdrawn 
claims 16 and 20. Furthermore, withdrawn claim 3 has been amended to depend from 
claim 1, and as such, withdrawn claims 3-15 are now appropriate for consideration with 
the Group 1 claims. In connection with the amendment to claim 3, claims 4 and 7 have 
also amended for consistency therewith. 

Next, turning to the Examiner's objection to claims 1-2 and 17-19, Applicants 
thank the Examiner for the careful review of the claims and the suggested amendments. 
The Examiner will note that Applicants have amended claims 1-2, 18 and 19 in the 
manner suggested by the Examiner. In addition, with respect to claim 17, this claim has 
been amended in an attempt to clarify the claim to address the issue raised by the 
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Examiner. Withdrawal of the objections to claims 1-2 and 17-19 are therefore 
respectfully requested. 

Next, turning to the art-based rejections, and more specifically to the rejection of 
independent claim 1, this claim generally recites a method for indexing a database table 
that comprises a column of values. The method includes identifying a plurality of 
substrings, where each substring comprises one or more characters, and, for each 
substring, creating a corresponding index over the column, where each corresponding 
index includes a respective entry for each value in the column, and where the respective 
entry for a particular value is indicative of whether a corresponding substring occurs in 
the particular value. 

In rejecting claim 1, the Examiner cites Shapira, arguing that the reference 
discloses all of the features recited in claim 1 with the exception of a "column," citing in 
particular col. 5, lines 1 1-30, col. 6, lines 28-30, and Figs. 2A and 2B. Shapira, however, 
is directed to a content filter that searches in parallel for multiple strings in a data stream, 
e.g., for use in applications such as network firewalls. It is important to note, however, 
that the reference is not directed to any algorithm for "indexing a database table," or for 
creating indices on a column in a database table, as recited in claim 1 . 

As discussed in the Application, e.g., at pages 2-4, an index is a term of art 
describing a data structure that accelerates the processing of database queries by 
providing information about a column in a database table that describes the contents of 
that column, and that often eliminates or reduces the need to retrieve the actual records in 
the database table to ascertain whether those records match certain values in that column. 
Within the context of claim 1 , the indices created by the recited steps are associated with 
specific substrings of characters, and the entries of such indices are used to indicate 
whether the substrings that such indices are associated with do or do not occur in the 
values that are associated with such entries. 

As an example, consider a database table that stores records with individuals and 
their home addresses, where one column of the database stores the home state. Using the 
steps recited in claim 1 , it might be desirable to create an index for the home state column 
that is associated with the substring "NEW", where each entry in the index is matched 
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with a particular value in the column. For records where the home state is "New York," 
"New Jersey," "New Mexico," etc., the corresponding entries in the index would indicate 
the presence of the substring in the values for those records. Conversely, for records 
where the home state is "Minnesota," "Kentucky," "Ohio," etc., the corresponding entries 
in the index would not indicate the presence of the substring in the values for those 
records. Consequently, should a database query be received that includes a parameter that 
looks for records where the state name includes the substring "NEW," a simple access to 
the index would eliminate the need to further consider any records where the associated 
entry in the index did not indicate a presence of the substring in the associated value. 

Shapira does not disclose or suggest any structure that corresponds to the indices 
recited in claim 1. Indeed, the term "index," as used in Shapira, is directed to an entirely 
different concept — that of a pointer to an entry in a table of substrings. Col. 5, lines 11- 
30, which the Examiner relies upon for disclosing an index, is actually directed to 
generating a hash function that enables data from an input stream to be compared against 
substrings stored in multiple tables. 

It is important to note that claim 1 recites creating an index for each of a plurality 
of substrings. Put another way, for each identified substring, a separate index is created 
for that substring. The index, once created, is used to identify whether the substring for 
that index occurs in each value in a column of a database table. 

In Shapira, in contrast, the substrings that are being searched are themselves 
stored in the tables, i.e., in the 3- and 2-char substring tables 22, 24 shown in Fig. 1. 
There is no data structure in Shapira that is analogous to an index that corresponds to a 
one particular substring. In fact, multiple substrings are stored in each substring table 22, 
24, e.g., as shown in Figs. 2A and 2B. 

Furthermore, claim 1 recites that for each index, an entry is provided for each 
value in a column of a table, and that each entry indicates whether the corresponding 
substring for the index occurs in the value. Given that in Shapira, the substrings 
themselves are stored in tables, Applicants fail to appreciate how Shapira meets this 
limitation of claim 1 . In addition, since the data being searched is in an input data stream, 
rather than in a table, Applicants assert that there is no data structure in Shapira that has 
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entries that indicate whether or not a particular substring occurs in a value found in any 
particular table, much less in a value found in a specific column of the table. 

The only data structure that even arguably functions as a type of index in Shapira 
is a hash table. As described in col. 5, lines 1 1-30 and col. 5, line 48 to col. 6, line 55, 
Shapira includes a hash look up table with 256 entries indexed via an 8-bit output of a 
hash function applied to data from a data stream input to the content filter. Each entry in 
the hash look up table includes an 8-bit pointer into a 256 entry substring table, where 
each entry in the substring table includes a substring. Of note, however, the hash table 
does not include an entry for each value in a column in the substring table, nor even for 
each entry in the substring table. Nor is any entry in the hash table indicative of whether 
a corresponding substring occurs in a particular value stored in the subject of that index — 
i.e., the substring table itself. 

Claim 1 recites "creating a corresponding index over a column, wherein each 
corresponding index includes a respective entry for each value in the column, the 
respective entry for a particular value being indicative of whether a corresponding 
substring occurs in the particular value." Applicants respectfully submit that Shapira 
does not disclose or suggest any analogous concept, and as such, claim 1 is novel and 
non-obvious over the reference. 

In fact, it should be noted that the indices created in the manner recited in claim 1 
may be used to search data stored in a table for the presence of a substring present in a 
database query. Put another way, the data being searched is in the table, and the search is 
based upon substrings present in a database query. Shapira, on the other hand, discloses 
more or less the opposite scenario - the substrings are stored in the table, but the data to 
be searched is not. 

Fritchman does not remedy the shortcomings of Shapira. Fritchman is cited for 
disclosing the concept of a column, at. col. 6, lines 55-57. Of note, however, the 
"column" being described in the cited passage refers to a column in a table in the text of 
the patent document, and apparently does not even refer to a table that is actually stored 
in a database. Nonetheless, the concept of a column in a database table is not new. 




Fritchman discloses an algorithm for parsing a search string into substrings to 
facilitate the processing of queries that include wildcards. Otherwise, there is no relevant 
teaching of any form of index that is associated with a particular substring, and that 
indicates the presence of such a substring within values in a column of a table. In fact, 
the only reference to indexing in Fritchman is found at col. 2, line 50 to col. 3, line 17, 
which discusses U.S. Patent No. 6,047,283, directed to a string indexing method that 
utilizes a search tree. Fritchman goes as far as to note that the Fritchman invention 
"matches strings against a pattern without requiring those strings to be indexed." (col. 3, 
lines 11-13). If anything, Fritchman teaches away from the use of indices. 

Accordingly, Applicants submit that one of ordinary skill in the art would not look 
to Fritchman to modify Shapira to incorporate indices having the specific characteristics 
recited in claim 1, e.g., indices that arc associated with particular substrings, and indices 
that include entries mapped to values in a database table column, with each entry 
indicating whether the associated substring occurs in the value with which the entry is 
mapped. 

Applicants therefore respectfully submit that independent claim 1 is non-obvious 
over Shapira and the other prior art of record. Reconsideration and allowance of claim 1, 
and of claims 2-15 which depends therefrom, are therefore respectfully requested. 

Next turning to the rejection of independent claim 17, this claim generally recites 
an apparatus for executing a query on a database table, where the table comprises a 
column of values. The apparatus includes, in part, a plurality of indices stored within a 
memory, where each index corresponds to one of a plurality of substrings and each index 
includes a respective entry for each value in the column. The claim also recites that the 
respective entry in each index is indicative of whether a corresponding substring to which 
such index corresponds occurs within the value for which the respective entry is included. 

As discussed above in connection with claim 1 , neither Shapira nor Fritchman, 
alone or in combination, discloses or suggests multiple indices, where each index 
corresponds to a particular substring, and where each index includes entries mapped to 
each value in a column in a database table, with each entry indicating whether the 
substring for that index occurs within the value to which the entry is mapped. 
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Accordingly, claim 17 is non-obvious over these references for the same reasons as 
presented above for claim 1 . 

Claim 17 also recites the concept of scanning the values of the table based on a 
combination of the plurality of indices. In rejecting claim 17, the Examiner apparently 
relies on Shapira, col. 3, lines 41-58, col. 5, lines 30-32, and col. 10, lines 24-26, and 
Fritchman col. 5, lines 46-48. 

With regard to Shapira, the cited passages do not even disclose scanning a 
database table, much less doing so based upon a combination of a plurality of indices. 
The cited passages do refer to a plurality of substrings, however, substrings are not 
indices, and particularly are not the types of indices recited in the claims and discussed in 
greater detail above. 

With regard to Fritchman, the cited passage merely refers to a pattern string that 
includes a combination of characters. However, a pattern string, substring, or set of 
characters is not an index within the context of Applicants' invention, much less a 
plurality of indices. Applicants submit that one of ordinary skill in the art would not be 
motivated by Fritchman to modify Shapira to scan a database table based upon a 
combination of a plurality of indices of the type recited in claim 17. 

Applicants therefore respectfully submit that independent claim 17 is also non- 
obvious over Shapira and the other prior art of record based upon this additional feature. 
Reconsideration and allowance of claim 17, and of claim 18 which depends therefrom, 
are therefore respectfully requested. 

Next, with regard to the rejection of independent claim 19, this claim generally 
recites a program product for indexing a database table. Similar to claim 1, this claim 
recites in part the identification of a plurality of substrings, where each substring 
comprises one or more characters, and for each substring, the creation of a corresponding 
index over the column, where each corresponding index includes a respective entry for 
each value in the column, and where the respective entry for a particular value is 
indicative of whether a corresponding substring occurs in the particular value. Claim 19 
is accordingly non-obvious over the prior art of record for the same reasons as presented 




above in connection with claim 1. Reconsideration and allowance of claim 19 are 
therefore respectfully requested. 

As a final matter, while Applicants traverse the rejections of the dependent claims 
based upon their dependency upon the aforementioned independent claims, Applicants 
note that a number of these claims recite additional features that are neither disclosed nor 
suggested by the prior art of record. In the interest of prosecutorial economy, however, 
these claims will not be discussed separately herein. Reconsideration and allowance of 
these claims are therefore respectfully requested. 

In summary, Applicants respectfully submit that all pending claims are novel and 
non-obvious over the prior art of record. Reconsideration and allowance of all pending 
claims are therefore respectfully requested. If the Examiner has any questions regarding 
the foregoing, or which might otherwise further this case onto allowance, the Examiner 
may contact the undersigned at (513) 241-2324. Moreover, if any other charges or credits 
are necessary to complete this communication, please apply them to Deposit Account 
23-3000. 
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